Distributed software development pipeline for coherent graphical user interface

ABSTRACT

A computer system includes memory and at least one processor. The memory stores a codebase, multiple reusable software modules, and computer-executable instructions. The codebase includes an application class extension, an activity class extension, a module base definition class, and a theme. The instructions include creating a software application using the application class extension and the theme from the codebase, registering at least one of the multiple reusable software modules to the software application, and configuring the software application to arrange navigation for each activity of each reusable software module registered to the software application, to present a same user experience throughout the software application. The instructions also include configuring the software application to automatically apply a same layout theme for each activity of each reusable software module registered to the software application, to present a same user experience throughout the software application.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/862,048 filed on Apr. 29, 2020; said application Ser. No. 16/862,048is a continuation-in-part of U.S. patent application Ser. No. 16/153,343filed Oct. 5, 2018. The entire disclosure of the applications referencedabove are incorporated by reference.

FIELD

The present disclosure generally relates to systems and methods forgenerating a software application and, in particular, to systems andmethods for generating software applications that maintain a consistentgraphical user interface (GUI) among disparate elements.

BACKGROUND

Software applications are often generated from different pieces coded bydifferent developers and, in particular, different software modules thatare independently coded by different developers (e.g., built, tested,debugged, etc. by different developers). Conventionally, the softwaremodules each define their own graphical user interface (GUI) as realizedby the respective developer. Accordingly, when one or more of thesoftware modules are integrated into a software application, the GUIprovided by each software module is often inconsistent with the GUI(s)provided by one or more other software modules integrated into thesoftware application and/or the overall GUI provided by the broadersoftware application itself. This leads to a poor user experience (UX)and often impairs the ability of the user to navigate between and accessfeatures provided by the software modules.

In addition, companies often develop different software applications forcustomers to use. Different teams of the company may create new softwaremodules each time a new software application is created, even if thereis a same or similar functionality provided by a software applicationmodule developed by another team. One reason for this is that borrowinga software application module from another team may lead to a poor UX.

Because of this, each software application module is often stored in acodebase that is specific to the team that developed the softwareapplication. Each team generally develops software applications usingonly the software application modules in its own codebase and,potentially, only the software application modules in a codebasespecific to the software application under development. This may lead todifferent codebases being designed and used for the development ofsoftware applications, duplication of effort, and increased difficultyin maintaining each application separately.

The background description provided here is for the purpose of generallypresenting the context of the disclosure. Work of the presently namedinventors, to the extent it is described in this background section, aswell as aspects of the description that may not otherwise qualify asprior art at the time of filing, are neither expressly nor impliedlyadmitted as prior art against the present disclosure.

SUMMARY

A computer-implemented method for generating a software applicationincludes creating at least one reusable software module by extending amodule base definition class from a codebase. The codebase includes anapplication class extension, an activity class extension, the modulebase definition class, and a theme. The method includes creating atleast one activity for the at least one reusable software module usingthe activity class extension from the codebase. The activity classextension provides a standardized layout and navigation handling thatapplies to all activities of all reusable software modules built fromthe activity class extension. The method also includes creating asoftware application using the application class extension and the themefrom the codebase, registering the at least one reusable software moduleto the software application, and configuring the software application toarrange navigation for each activity of each reusable software moduleregistered to the software application, to present a same userexperience throughout the software application. The method furtherincludes configuring the software application to automatically apply asame layout theme for each activity of each reusable software moduleregistered to the software application, to present a same userexperience throughout the software application.

In other features, configuring the software application to automaticallyapply a same layout theme includes configuring the software applicationto apply an application-wide override theme on top of a default themefor the at least one activity at startup of the at least one activity.In other features, the computer-implemented method includes configuringthe at least one activity to set a user interface for a screen of the atleast one activity, wherein content of the user interface is determinedby the at least one activity and arrangement of toolbars and navigationanchors of the user interface is determined by the software application.

In other features, the computer-implemented method includes creating atleast one fragment for the at least one reusable software module using afragment class extension from the codebase, the fragment class extensionproviding a standardized layout and navigation handling that applies toall fragments of all reusable software modules built from the fragmentclass extension. The method includes configuring the softwareapplication to arrange navigation for each fragment of each reusablesoftware module registered to the software application, to present asame user experience throughout the software application, andconfiguring the software application to automatically apply a samelayout theme for each fragment of each reusable software moduleregistered to the software application, to present a same userexperience throughout the software application.

In other features, creating the at least one reusable software moduleincludes creating a plurality of reusable software modules, where eachreusable software module includes at least one corresponding activity,and registering the reusable software module to the software applicationincludes registering at least two of the plurality of reusable softwaremodules into the software application.

In other features, the computer-implemented method includes updating atleast one of the plurality of reusable software modules and registeringthe updated at least one reusable software module to the softwareapplication when a previous version of the at least one reusablesoftware module was registered to the software application prior toupdating the at least one reusable software module. In other features,the computer-implemented method includes updating at least one of theplurality of reusable software modules and maintaining an originalversion of the at least one reusable software module in the softwareapplication when the original version of the at least one reusablesoftware module was registered to the software application prior toupdating the at least one reusable software module.

In other features, at least one of the plurality of reusable softwaremodules comprises a general reusable software module from which at leastone other reusable software module depends. In other features, thecomputer-implemented method includes integrating the general reusablesoftware module into the software application and removing one of the atleast two other reusable software modules from the software application.

In other features, creating the reusable software module includesobtaining common UI and core services components from an operatingsystem, creating the software application includes creating login andauthentication hooks using the obtained core services components, andthe method includes deploying the software application to a digitaldistribution platform. In other features, the codebase further includesa fragment class extension, and the application class extension, theactivity class extension, and the fragment class extension compriseextensions of base application, activity and fragment classes of anANDROID operating system.

In other features, a computer system includes memory configured to storea codebase, multiple reusable software modules, and computer-executableinstructions. The codebase includes an application class extension, anactivity class extension, a module base definition class, and a theme.Each reusable software module is an extension of the module basedefinition class from the codebase and includes at least one activitybuilt from the activity class extension of the codebase. The activityclass extension provides a standardized layout and navigation handlingthat applies to all activities of all reusable software modules builtfrom the activity class extension. The at least one processor isconfigured to execute the instructions. The instructions includecreating a software application using the application class extensionand the theme from the codebase, registering at least one of themultiple reusable software modules to the software application, andconfiguring the software application to arrange navigation for eachactivity of each reusable software module registered to the softwareapplication, to present a same user experience throughout the softwareapplication. The instructions also include configuring the softwareapplication to automatically apply a same layout theme for each activityof each reusable software module registered to the software application,to present a same user experience throughout the software application.

In other features, configuring the software application to automaticallyapply a same layout theme includes configuring the software applicationto apply an application-wide override theme on top of a default themefor each activity at startup of each activity. In other features, eachactivity includes a user interface for a screen of the activity, contentof the user interface is determined by the activity, and arrangement oftoolbars and navigation anchors of the user interface is determined bythe software application.

In other features, the codebase incudes a fragment class extension, eachreusable software module includes at least one fragment built from afragment class extension from the codebase, the fragment class extensionprovides a standardized layout and navigation handling that applies toall fragments of all reusable software modules built from the fragmentclass extension, and the instructions further include configuring thesoftware application to arrange navigation for each fragment of eachreusable software module registered to the software application, topresent a same user experience throughout the software application. Theinstructions also include configuring the software application toautomatically apply a same layout theme for each fragment of eachreusable software module registered to the software application, topresent a same user experience throughout the software application.

In other features, the codebase further includes a fragment classextension, and the application class extension, the activity classextension, and the fragment class extension comprise extensions of baseapplication, activity and fragment classes of an ANDROID operatingsystem.

A computer-implemented method for generating a library of reusablesoftware modules includes creating a first reusable software module byextending a module base definition class from a codebase. The codebaseincludes an application class extension, an activity class extension, afragment class extension, the module base definition class, and a theme.The method includes creating at least one activity for the firstreusable software module using the activity class extension from thecodebase. The activity class extension provides a standardized layoutand navigation handling that applies to all activities of all reusablesoftware modules built from the activity class extension. The methodincludes storing the first reusable software module in the library ofreusable software modules, creating a second reusable software module byextending the module base definition class from the codebase, creatingat least one activity for the second reusable software module using theactivity class extension from the codebase, creating at least onefragment for the at least one activity of the second reusable softwaremodule using the fragment class extension from the codebase, and storingthe second reusable software module in the library of reusable softwaremodules. The library of reusable software modules facilitates creationof a software application using the application class extension and thetheme from the codebase, facilitates registration of the first andsecond software modules to the software application, and facilitatesconfiguration of the software application to arrange navigation for eachactivity and fragment of the first and second reusable software modulesand to apply a same layout theme for each activity and fragment of thefirst and second reusable software modules in in order to present a sameuser experience throughout the software application.

In other features, the computer-implemented method includes creating atleast one fragment for the at least one activity of the first reusablesoftware module using the fragment class extension from the codebase.The fragment class extension provides a standardized layout andnavigation handling that applies to all fragments of all reusablesoftware modules built from the fragment class extension. The methodincludes creating at least one fragment for the at least one activity ofthe second reusable software module using the fragment class extensionfrom the codebase.

In other features, the computer-implemented method includes updating thefirst reusable software module and providing the updated first reusablesoftware module to a software application when a previous version of thefirst reusable software was registered to the software application priorto updating the first reusable software module. In other features, thecodebase further includes a fragment class extension, and theapplication class extension, the activity class extension, and thefragment class extension comprise extensions of base application,activity and fragment classes of an ANDROID operating system.

Further areas of applicability of the present disclosure will becomeapparent from the detailed description, the claims, and the drawings.The detailed description and specific examples are intended for purposesof illustration only and are not intended to limit the scope of thedisclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure will become more fully understood from thedetailed description and the accompanying drawings.

FIG. 1 is a functional block diagram of an example system for generatinga software application, according to some aspects of the presentdisclosure.

FIGS. 2A and 2B illustrate an example process of migrating dependenciesof a software application among different software modules in the systemof FIG. 1 .

FIG. 3 is a message sequence chart showing example interactions betweencomponents of the system of FIG. 1 during an example process ofgenerating a software application.

FIG. 4 is a flowchart depicting an example method for creating asoftware module.

FIG. 5 is a flowchart depicting an example method for creating asoftware application.

FIG. 6A is a flowchart depicting an example method for starting up asoftware application.

FIG. 6B is a flowchart depicting an example method for starting up anactivity of a software application.

FIG. 7 is a functional block diagram of an example system of the presentdisclosure suitable for use in generating software applications.

FIG. 8 is a functional block diagram of a computing device that may beused in the example system of FIG. 7 .

In the drawings, reference numbers may be reused to identify similarand/or identical elements.

DETAILED DESCRIPTION Introduction

In the scenario described above, different teams may develop custom orsingle-use code. Alternatively, one team may develop a softwareapplication module and recognize that it may be used by other teams, sothe module may be cloned to be used in other applications. The modulemay present identical (or nearly identical) experiences to anapplication end-user, such as a customer. However, each softwareapplication that incorporates the module is an entirely separate projectand codebase, each of which must be updated, maintained, and testedindependently.

The inventor has developed a framework or a platform for writingsoftware applications (also known as apps). The framework may include asingle application codebase, which is used to generate software modulesthat are then used to make the app. More than one application may useeach software module, but the software module may not be cloned for eachapp. Instead, the author or owner of the software application takescertain steps to incorporate the application codebase into the softwareapplication. Thus, when a change needs to be made to the module, themodule developer modifies that module once, and the change isdistributed to each application that uses the module. In practice, themodule developer updates and releases a new version of that module to acontent repository such as the Apache Maven software project managementtool. Then, application owners/authors may update their apps to thelatest version of the module to consume the changes. App owners/authorscan also choose to remain on specific/older versions depending on theiruse case.

In addition, the systems and methods described herein uniquely providefor generating (e.g., linking, compiling, etc.) a software applicationand, in particular, generating a software application that is based onone or more independently developed software modules while maintaining aconsistent graphical user interface (GUI). In various implementations,an application configuration engine is configured to retrieve multiplesoftware application modules (e.g., from a module repository, etc.).Each software application module includes a re-usable logic and providesone or more screens (e.g., activities or fragments, etc.). Each screenincorporates (e.g., extends, etc.) a screen model (e.g., an activity orfragment model, etc.) from a codebase (referred to below as “AppBase” inone example).

The screen model integrated by each screen of the software applicationmodule provides an aspect of a GUI for the screen (e.g., a layout forthe screen, content for navigation of the screen, content for a menu ofthe screen, content for a toolbar of the screen, etc.). The softwaremodules are then integrated into the software application (e.g., anAndroid application, etc.). The software application incorporates (e.g.,extends, etc.) a software application model from the codebase. Thesoftware application model also provides one or more aspects of the GUI(e.g., navigation for the screens provided by each software module, atheme for the screens provided by each software module, etc.). In thismanner, common screen models and/or application models may beincorporated by software modules and/or software applications to helpensure that the software application integrating the software provides aconsistent GUI to the user.

Further, the software application may be configured to receive acredential of a user of the software application and store thecredential for distribution to the software modules integrated into thesoftware application, such that the software modules can use thecredential without having to re-obtain the credential each time thecredential is needed to authenticate the user (e.g., for one or moreservices provided to or accessed by the software modules, etc.).

Software Development System Devices

FIG. 7 illustrates an example system 600 in which one or more aspects ofthe present disclosure may be implemented. Although the system 600 ispresented in one arrangement, various implementations may include someor all of the parts of the system 600 (or additional parts) arranged ina different manner. In the example embodiment of FIG. 7 , the system 600includes a module development engine 602, a codebase 604, a modulerepository 606, an application configuration engine 608, a digitaldistribution platform (e.g., application repository) 610, a user device612, a module developer device 614 and an app developer device 616. Forexample, the user device 612, module developer device 614 and appdeveloper device 616 may include any suitable mobile phone, computer,etc.

As described in more detail throughout the present disclosure, thedevelopment engine 602 is generally configured to generate one or moresoftware application modules that incorporate (e.g., extend) a screenmodel from the codebase 604. The development engine 602 is generallyconfigured to store the software application modules in the modulerepository 606. The application configuration engine 608 is generallyconfigured to retrieve one or more software application modules from themodule repository 606 and integrate (e.g., compile and link) thesoftware application modules into a software application stored in thedigital distribution platform 610 (e.g., GOOGLE PLAY, APPLE APP STORE,etc.). The software application may be downloaded, installed, etc., fromthe digital distribution platform 610, and when executed by a processorof the user device 612, may cause the user device to provide one or morefunctions consistent with a logic included in the software applicationwhile providing a consistent GUI to a user of the user device 612.

FIG. 8 illustrates an example computing device 700 that can be used inthe system 600. The computing device 700 may include, for example, oneor more servers, workstations, personal computers, laptops, tablets,smartphones, etc. In addition, the computing device 700 may include asingle computing device, or it may include multiple computing deviceslocated in close proximity or distributed over a geographic region, solong as the computing devices are specifically configured to operate asdescribed herein. In the example embodiment of FIG. 7 , the developmentengine 602, the application configuration engine 608, the user device612, the module developer device 614 and the application developerdevice 616 may each include one or more computing devices consistentwith computing device 700. The codebase 604, the module repository 606,and the digital distribution platform 610 may also each be understood tobe consistent with the computing device 700 and/or implemented in acomputing device consistent with computing device 700 (or a partthereof, such as, e.g., memory 804, etc.). However, the system 600should not be considered to be limited to the computing device 700, asdescribed below, as different computing devices and/or arrangements ofcomputing devices may be used. In addition, different components and/orarrangements of components may be used in other computing devices.

As shown in FIG. 8 , the example computing device 700 includes aprocessor 702 including processor hardware and a memory 704 includingmemory hardware. The memory 704 is coupled to (and in communicationwith) the processor 702. A presentation unit 706 may output information(e.g., interactive interfaces, etc.), visually to a user of thecomputing device 700. Various interfaces (e.g., as defined by softwareapplications, screens, screen models, GUIs etc.) may be displayed atcomputing device 700, and in particular at presentation unit 706, todisplay certain information to the user. The presentation unit 706 mayinclude, without limitation, a liquid crystal display (LCD), alight-emitting diode (LED) display, an organic LED (OLED) display, an“electronic ink” display, speakers, etc. In some embodiments,presentation unit 706 may include multiple devices. Additionally oralternatively, the presentation unit 706 may include printingcapability, enabling the computing device 700 to print text, images, andthe like on paper and/or other similar media.

In addition, the computing device 700 includes an input device 708 thatreceives inputs from the user (i.e., user inputs). The input device 708may include a single input device or multiple input devices. The inputdevice 708 is coupled to (and is in communication with) the processor702 and may include, for example, one or more of a keyboard, a pointingdevice, a mouse, a stylus, a touch sensitive panel (e.g., a touch pad ora touch screen, etc.), or other suitable user input devices. In variousimplementations, the input device 708 may be integrated and/or includedwith the presentation unit 706 (for example, in a touchscreen display,etc.). A network interface 710 coupled to (and in communication with)the processor 702 and the memory 704 supports wired and/or wirelesscommunication (e.g., among two or more of the parts illustrated in FIG.7 ).

Referring again to FIG. 7 , the development engine 602, applicationconfiguration engine 608, the user device 612, the module developerdevice 614 and the app developer device 616 are each specificallyconfigured by computer-executable instructions to perform one or more ofthe operations described herein. In the illustrated embodiment, thedevelopment engine 602, application configuration engine 608, the userdevice 612, the module developer device 614 and the app developer device616 are each shown as a standalone part of the system 600. In variousimplementations, the development engine 602, the applicationconfiguration engine 608, the user device 612, the module developerdevice 614 and/or the app developer device 616 may be incorporatedtogether (e.g., as a single computing device 700). Alternatively oradditionally, in various implementations the development engine 602, theapplication configuration engine 608, the user device 612, the moduledeveloper device 614 and/or the app developer device 616 may beincorporated be associated with, or incorporated with, still other partsof the system 600: for example, the codebase 604, the module repository606, or the digital distribution platform 610, etc. Further, in variousembodiments, the development engine 602, the codebase 604, the modulerepository 606, the application configuration engine 608, the digitaldistribution platform 610, the module developer device 614 and the appdeveloper device 616 may be embodied in at least one computing device700 and accessible as a network service (e.g., a web service such as acloud-based service, etc.), via, for example, an application programminginterface (API), etc.

The development engine 602 includes an integrated developmentenvironment (IDE). The development engine 602 is configured to generatemultiple software modules (e.g., in Java, etc.). The example softwaremodules relate to services provided by a health insurance provider.However, the software modules may relate to any other type of service orfunctionality in one or more other embodiments. Each software moduleincludes re-usable logic (broadly, code) that, when executed by aprocessor 702 of the mobile device 712, causes the mobile device 712 toprovide one or more functionalities to a user of the mobile device 712.The software modules may include, for example, a journaling module thataccepts and stores user input in a memory 704 of the mobile device 712to track the health or wellbeing of the user; a customer relationshipmanagement (CRM) messaging module that provides an inbox of messagesfrom the health insurance avoider for the user displays promotions(e.g., advertisements, business promotions, etc.) to the user; aclick-to-chat (C2C) module that allows a user to initiate andparticipate in a chat session with an agent of the health insuranceprovider; and a mapping module that displays maps that identifylocations of the health insurance provider.

Other software modules may include, for example, a programs module thatguides the user through a number of planned activities for specificpurposes (e.g., well-being purposes, etc.); a telehealth module thatprovides integrated video conferencing with medical professionals inreal-time and associated scheduling functionality; a user assessmentmodule that provides a series of questions (e.g., health or well-beingquestions, etc.) to elicit responses from the user; an updates modulethat provides updates from the health insurance provider (e.g., newservices or offerings, updates regarding the user's insurance coverage,etc.); a curated moment module that provides, for example, a curation ofdifferent health events of the user; a messaging module that provides,for example, the ability for a user to interact in a live-chat with adesignated agent; a FIDO (Fast Identity Online) module that providesauthentication (e.g., biometric authentication, etc.) for the user toaccess services or information provided through the other modules; and adatabase module that provides for persistent or temporary storage ofdata related to the other modules. In one or more other embodiments, thesoftware modules may provide any of a variety of other functionalitiesor services.

The software modules each include re-usable logic (e.g., a code, amethod, a function, etc.) that carries out the above describefunctionalities. The logic of each software module is re-usable in thatthe logic and, thus, the software module may be incorporated into any ofa variety of different software applications that may integrateddifferent combinations of software modules.

The software modules also each provide one or more screens. Each screenmay include one or more panes. The example software modules provide oneor more screens that each include an Android activity, where eachactivity may include one or more fragments. Each screen and, moreparticular, each activity or fragment, provides a window in which asoftware application incorporating the software module providing thescreen/pane/activity to draw a graphical user interface (GUI) for thescreen/pane/activity. Conventionally, a software module providing thescreen/pane/activity is generally responsible for providing (e.g.,defining, specifying, drawing, etc.) all aspects of the GUI for thescreens/panes/activities (e.g., in Android application development,etc.). Software modules and the screens/panes/activities providedthereby, however, are often each developed by different developmentsteams. As a result, the GUIs for the screens/activities provided by thedifferent software modules are often inconsistent and lead to a pooruser experience. And, even where software modules may be developed bythe same team, development becomes redundant and inefficient when eachsoftware modules must be independent developed to provide a consistentGUI.

To address these problems the example software modules each incorporate(e.g., extend, etc.) a screen model from the codebase 604. The examplescreen model includes an activity model and a fragment model, where theactivity model may be incorporated or extended by screens/activities ofthe software modules and the fragment model may be imported or extendedby screens/fragments of the software modules. And, the example codebase604 includes a data structure. In the illustrated example, codebase 604is an Android codebase. In one or more other embodiments, the codebase604 may include a different type of codebase (for example, an iOScodebase, etc.).

In any case, the screen model provides one or more aspects of the GUIfor each screen incorporating or extending the screen model. The one ormore aspects of the GUI provided by the screen module include a layoutfor the screen, a content for a navigation for the screen, a content fora menu of the screen, and/or a content for a toolbar for the screen.

The development engine 602 is configured to store the generated softwaremodules in the module repository 606 (a Nexus repository, etc.). Theapplication configuration engine 608 (e.g., an IDE, etc.) is configuredto retrieve any combination of one or more software modules form themodule repository 606 and integrate (e.g., compile, etc.) the softwaremodules retrieved from the module repository 606 into a softwareapplication that incorporates a software application model from thecodebase 604. The software application model also provides one or moreaspects of the GUI for each screen/activity/fragment provided by eachsoftware module integrated into the software application that extendsthe software application model. The one or more aspects of the GUIprovided by the example software application model may include, forexample, a navigation for each screen/activity/fragment provided by thesoftware modules (e.g., to navigation between the screens/activities/fragments provided by an individual software module, etc.); a navigationfor the overall software application (e.g., to navigate from softwaremodule to software module, etc.); a theme from the codebase 604 for eachscreen/activity/fragment provided by the software modules; a theme fromthe codebase 604 for the overall software application; and/or a menu ora toolbar for each screen provided by the software modules.

In various implementations, the development engine 602 and/or theapplication configuration engine 608 may be configured to modify any oneor more of the software modules to override any one or more aspects (orat least part) of the GUI provided by the screen model and/or thesoftware application. In this manner, the software application mayprovide a consistent UX to the user of the software application whileallowing for module-specific customizations.

In addition, the example software application, when executed by aprocessor of the user device 612, may be configured to receive acredential (e.g., a biometric, a token, a username/password, etc.) of auser of the software application (e.g., via the GUI or an operatingsystem of the user device 612, etc.) and store the credential in amemory 604 accessible by the software application. Such receipt andstorage may be performed, for example, by a FIDO module integrated intothe software application. In any case, the software application isconfigured to (e.g., via the FIDO module, etc.) distribute thecredential to one or more other software modules integrated into thesoftware application, such that the software modules may use thecredential without having to re-obtain the credential each time thecredential is needed to authenticate the user (e.g., for one or moreservices provided or accessed by the software modules, etc.).

With the software modules integrated into the software application, theapplication configuration engine 608 is configured to publish thesoftware application to the digital distribution platform 610 forretrieval by the user device 612, whereby the user device 612 mayretrieve and execute the software application.

Software Module and Application Relationships

FIG. 1 is a block diagram of a system 100 for generating a softwareapplication according to various implementations. The system 100 isdescribed in reference to a particular codebase 604, referred to here asAppBase 10. More particularly, the system 100 includes software modules20 (e.g., software application modules consistent with those describedabove in reference to the example system 600, etc.), common userinterface (UI) components 17, and a core services library 19. Broadly,AppBase 10 is used to generate one or more software modules 21-23 withthe help of common UI components 17 and core services library 19.

Access to each software module is then included in the code for one ormore software applications 30 (of which 4 are illustrated), which sharethe module and its functionality. Software applications 30 may be anytype of software program generally intended for use by an end-user(e.g., of a user device 612 running the software applications 30, etc.),and include what are colloquially called “apps,” which are used onsmartphones, tablets, and other mobile devices. Software applications 30are not, however, limited to “apps” or to use on mobile devices, and maybe deployed on any type of desktop, laptop, or other computer. Softwareapplications 30 may pull in and use the core services and common UIcomponents and may use any combination of software modules withoutrequiring separate configuration.

During development, a module developer may use the AppBase 10 togenerate or produce modules 20 (e.g., via a development engine 602,etc.) and store the modules 20 (e.g., in the module repository 606,etc.), where the modules 20 are consumed by an app owner (e.g., byretrieving the modules 20 from the module repository 606, etc.). The appowner generates the app 30 (e.g., via an application configurationengine 608, etc.) and provides it to an end user (e.g., via a digitaldistribution platform 610, etc.). The module developer also generates orproduces updates to the modules 20, which may be incorporated into theapp 30 by the app owner (e.g., by retrieving the updated modules 20 fromthe module repository 606, etc.). Subsequently, the end-user may updatethe app 30 with updates provided by the app owner (e.g., via the digitaldistribution platform 610, etc.).

One embodiment of the invention may be implemented using an Androidoperating system 5 (which in turn is built on the Java programminglanguage), which will be used to illustrate aspects of the invention.The AppBase 10, implemented using the operating system 5, includesextensions to the Android standard base classes (broadly, base models),such as of Application, Activity, and Fragment, a Module class, and aTheme, which provide common functionality. “Class” is a term used in thecontext of Java to represent code that generally provides a model orblueprint that serves as a template for creating (or instantiating)specific objects (e.g., activities, fragments, etc.) within a program.In connection therewith, the class generally provides initiate valuesand implements of behaviors (functions or methods) that may be used orexpanded upon by the objects integrated (e.g., extending) the class. An“activity” may be a screen presented to an end-user, and a singleactivity may present multiple “fragments” (e.g., panes of the screen,etc.) to the end-user. These fragments may be independent of each otheror may share data via the activity. Thus, every screen an end-user seesin an Android application is either an activity or a fragment, and theyare all held together by the application class. A Theme is a collectionof color, image, and size resource values that will be applied to theentire application. The AppBase 10 extends (adds functionality to) theApplication, Activity, and Fragment classes. In order to use the AppBaseframework/platform, each application and module must be built using theAppBase versions of these classes.

AppBase 10 supports design, development, and inclusion of softwaremodules 20. In this embodiment, AppBase 10 includes an Application ClassExtension 11, an Activity Class Extension 12 (e.g., a screen modelconsistent with that which is described above in reference to theexample system 600, etc.), a Fragment Class Extension 13 (e.g., a screenmodel consistent with that which is described above in reference to theexample system 600, etc.), a Module Base Definition class 14, and aTheme 15 (e.g., a theme consistent with that which is described above inreference to example system 600, etc.). The Extensions 11, 12 and 13 maybe considered as OS-Specific Extensions 9. The Extensions 11, 12 and 13are related to the Android operating system, although variousimplementations could use other extensions, other operating systems etc.

The software modules 20 may be extensions of the Module Base Definitionclass 14. For example, the AppBase 10 may define what a module 20 isthrough JAVA polymorphism, etc. The individual modules 20 inherit thedefinitions from the AppBase 10 (e.g., via the Module Base Definitionclass 14).

AppBase 10 may also include analytics code; “AppCenter” (e.g. hockeyApp)code, which is Microsoft® utility code that manages application releasesand tracks issues in deployed code; common and system utilities; datastorage; module interface definition; HTTP (global) request/responseprocessing; and Android M (a version of the Android OS) permissionshandling. (Compared to previous versions of the Android OS, Android Mchanged the way the system handles permissions (to access storage,camera, etc.). The permissions utility code makes it easier for appowners using AppBase 10 to leverage the new calls without concern for OSversion or system limitations.)

AppBase 10 is used to create one or more software modules 20, whichrepresent self-contained functionalities that are larger than a single“component” but smaller than an entire software application 30. A“component” in this context is a single item within a larger Activity orFragment (i.e. screen/page). Modules 20 are used to specify largerlogical blocks such as complex calculations, a series of screens, oradvanced data processing. These typically consist of many componentsworking together. Modules are built on top of AppBase 10 (e.g., byintegrating, extending, etc. models included within the AppBase 10,etc.) and use a standard theming technique (e.g., uniformly applied bythe software application to the modules 20, such as screens provided bythe modules 20, etc.), so that when they are used in an application theydo not appear out of place.

Notwithstanding the standard theming technique, the modules 20 arehighly configurable in that they can be customized to differentapplications 30, languages, themes, and/or storage methodologies.Modules 20 are functional on their own, so they can be plugged(referenced/pulled-in via a build file and loaded via a singleInitialize call at application boot) into any application 30 built usingAppBase 10, and operate without other considerations or requirements.Almost always, modules 20 provide a series of configurations so thatapplications 30 can customize their behavior, but the default valueswill result in a valid functional and generally standardized experience.Modules 20 are independent of each other, are application agnostic, andprovide interfaces and callbacks so that applications 30 can injectalternate or app-specific data as required. Specific modules 20 (such asthose that connect to distinct application programming interfaces (APIs)or services) may include their own network handling. When a network isrequired, because, e.g., the module 20 needs to retrieve data from someplace other than the local device (i.e. a server), the module 20 definesits own environment and specifies by key when making calls. Softwareapplications 30 are allowed to and are able to replace environmentconfigurations at compile time.

Software modules 20 contain string resources for all supportedlanguages—the software application itself should be written to lock theend-user into its desired regional support. In the Android OS, stringresources typically comprise a file with all user-visiblestrings/sentences within it, and that file is referenced from theapplication code so that the application 30 can display in a differentlanguage by changing the file reference. AppBase 10 may automaticallylock the user into regional support (“locale locking”) using valueswithin a configuration file (which may be named “config.xml”) that canbe overridden by any application. Applications 30 are able to addlanguage support with varying results by providing additionaltranslation files. For example, an application may support morelanguages than its modules do, in which case, the end-user would bepresented with different languages in different sections of theapplication. (i.e., the main app can be written to support English,Spanish, and French, but if Module A supports only English and Spanish,and Module B supports only French, end-users set to those locales wouldsee varying content as they navigate through the app. Applications thatsupport more languages than modules do are able to provide thetranslation files for module-strings at compile time, to prevent thedifferent-language-on-different-screens scenario.

As shown in FIG. 1 , the applications 30 may use only one module 20,multiple modules 20, or all modules 20. For example, the application 31uses only the software module 22, while the application 32 uses both thesoftware module 21 and the software module 22. The application 34 alsouses two modules, while the application 33 uses all three of the modules21, 22 and 23. FIG. 1 also illustrates that the software applications 30may incorporate the common UI components 17 and the core serviceslibrary 19 from the operating system 5, as well as the extensions 11-15from the AppBase 10. The modules 20 may also use the common UIcomponents 17 and the core services library 19 from the operating system5.

FIGS. 2A and 2B illustrate examples of migrating dependencies among thesoftware applications 30 and the modules 20. For example, some modules20 may depend on other modules 20 as well. As shown in FIG. 2A, ageneral telehealth module 24 wraps a first telehealth provider module 25and a second telehealth provider module 26. The module 22 depends on thesoftware module 23. For example, modules may reference each other byutilizing ‘deeplinks’ which are managed by example frameworks describedherein (e.g., the module 22 can ‘fire’ a deeplink which is intended forthe module 23, but if the application 30 does not include the module 23an error may be shown to the user).

Each software application 30 may communicate with, incorporate, use,etc., general or specific modules 20. For example, in FIG. 2A, theapplication 30 uses the general telehealth module 24, while theapplication 32 uses the specific second telehealth provider module 26.The dependencies may be migrated as different modules 20 are developed.

For example, if the application 32 used the second telehealth providermodule 26 historically, and the general telehealth module 24 issubsequently deployed to wrap the second telehealth provider module 26,the application 32 may change its module dependencies to incorporate thegeneral telehealth module 24 instead of the second telehealth providermodule 26. This change is illustrated in FIG. 2B. The applications 30may have the option of changing over to the general module 24 as desired(FIG. 2B), or may continue relying on the specific module 26 (FIG. 2A),according to the application developer preferences.

One example environment for embodiments of this invention is ingenerating “apps” 30 for healthcare management. In such embodiments,there may be two types of software modules 20—functional modules 20 andactivity modules 20. A functional module provides reusable logic andmethods, but does not define any UI (e.g., a GUI, etc.) or activities(e.g., screens, etc.). Examples of functional modules 20 are a “CoreServices” module 20 and a “wearables” module 20. In an embodiment, a“Core Services” module 20 may perform, among other things, networkservices, environment/server definition, authentication handling, tokenand cookie management, and request/response processing. A Core Servicesmodule 20 will be discussed in more detail below. In an embodiment, a“wearables” module 20 may integrate with wearable devices (e.g.,Garmin®, Jawbone®) and may report to the application 30 on the availabledata (e.g., step counts, etc.).

An activity module 20 provides reusable logic or methods (like afunctional module 20), but also defines its own activities (e.g.,screens, etc.) and UI (e.g., GUI, etc.). For example, one or moreaspects (e.g., a layout, etc.) of the GUI are provided by a screen model(e.g., Activity Class Extension 12, etc.) incorporated (e.g., extended,etc.) by the activities, and sometimes its own navigational flow (e.g.,where the navigational flow is provided by the application 30 thatextends a software application model such as the Application ClassExtension 11, etc.). Examples of activity modules are a “journal” module20 and a “programs” module 20.

In an embodiment, a “journal” module 20 may provide a record of anend-user's user experience (UX) and database, for accepting and storinga variety of user input locally on the device using the softwareapplication 30. Such a journal module 20 may be capable of handlingin-app deep links using configured keys. In an embodiment, a “programs”module 20 may control, present, store, and allow interaction with a setof programs intended to guide end-users through some number of plannedactivities for specific purposes. Such a module 20 may include servicelayer interaction for update and storage. One or more of these softwaremodules 20 may be configured using “JSON” (JavaScript Object Notation),which is a data-interchange format, or may interact with JSON-definedelements. Both of these activity modules 20 may provide their ownnavigational flow (e.g., the navigational flow provided by the softwareapplication model extended by the application 30 or by overriding thisnavigation flow, etc.) by having a defined navigational path from A->Z(e.g., from activity A to activity Z, etc.), rather than a collection ofsingle activities (e.g., selectable from a menu, etc.). These modules 20also allow apps 30 to step in to the navigational flow at several pointsby providing specific information. A journal module 20, for example, maybring an end-user to a list of all entries, or to directly create a newentry of a certain type— each of these may have a specific navigationanchor presented to the end-user from the main application 30.

Examples of other software (activity) modules 20 in this embodiment area “CRM Messaging” module 20, a “Click to Chat” module 20, a “Maps andLocation” module 20, a “Telehealth module 20, a “User Assessment” module20, a “Library/Articles” module 20, and a “Directory” Module 20. The“CRM Messaging” module 20 processes messages and UX, includingconnection points for application control of user actions. This moduledisplays business promotions to the end-user, including a view pager andan “inbox.” The “Click to Chat” module 20 allows an end-user to initiateand complete a Chat-with-an-agent session within a software application30. The “Maps and Location” module 20 controls and displays all map andlocation information to an end-user with a standardized interface acrossdevice types. The “Telehealth” module 20 includes integrated videoteleconference to consulting doctors, including scheduling and otherfunctionality. The “User Assessment” module 20 provides aJSON-configured series of questions that will result in distinct,calculated responses. The “Library/Articles” module 20 is located on thepresentation layer for JSON-configured series of articles, sourcedeither on the end-user's device or on a remote server. This module iscapable of deep-linking directly to software applications 30 or ofhandling in-app deep links using configured keys. The “Directory” module20 acts like the Yellow Pages for in-network medical services.

The core services library 19 may include presentation of a mobile APIlayer, data caching (session management), generic servicerequest/response processing, environment switching and management,username+password and FIDO/fingerprint capabilities (“FIDO,” a touchlDfunction, stands for “fast identity online”), and MFA capabilities,which may include token MFA, in which an end-user logs in and is sent atoken to the end-user's e-mail address or cell phone for confirmationand subsequent input before being allowed to use the app. Core serviceslibrary 19 may provide the networking backbone for Android applications30 developed using system 100, including Web SEAL and ISAM (IBM SecurityAccess Manager) server platforms. It may support local data and othertest environments. It may also allow concurrent connections to multipleservers, provided they use identical credentials. Core services library19 may also include an HTTP connections layer.

Common UI components 17 may include individual components that providemore functionality than basic Android components. Components created forany project that can be built and configured in a generic way, topromote reuse and uniformity across applications. Common UI components17 may include components that support standard theming and may specifycustom attributes as appropriate. Custom components may havestandardized inputs, charts and graphs, and system extensions.Components may also promote debugging of the UI, may handle photo,video, and/or audio, and may include utilities such as bitmap managementand style management.

In an embodiment, common UI components 17 contains a single AndroidStudio project with two modules, an “app” module and a “commonUltest”module. The “app” module contains CommonUl library code. The“commonUltest” module is an Android project with a test harness, as wellas sample layouts and usage of the components. Both are stored andcommitted in a software repository as often as they are altered, butonly the “app” module is exported to a specific implementation of aMaven repository (e.g., a module repository 606, etc.) used by thedeveloper for later access (e.g., in generating a software applicationusing the application configuration engine 608, etc.). The CommonUllibrary is exported as an .aar file, which means that all resources andstrings contained within it are available for use in projects thatreference it, in addition to the classes.

The blocks shown in FIG. 1 are examples of parts that may comprisesystem 100 and do not limit the blocks or parts that may be connected toor associated with these parts. The blocks in FIG. 1 may be implementedin software or hardware or a combination of the two, and may includememory for storing software instructions. Authentication protocolsdescribed above include username+password and FIDO/fingerprint, butother methods of authenticating users may be used. Moreover, as statedearlier, this block diagram can be applied to a system using anoperating system other than Android. Application, activity, and fragmentclasses are generally files of code, as is module class 14. Otheroperating systems include libraries or modules similar to common UIcomponents 17 and core services library 19.

Message Sequence Chart

In FIG. 3 , example interactions between the operating system 5, theAppBase 10, a software module developer 20-1, a software applicationdeveloper 30-1 and a digital distribution platform 40 are illustrated,during a process of creating and deploying an application 30 using oneor more software modules 20. At 204, the AppBase 10 supplies extensions,definitions and themes to the software module developer 20-1, and at 208the operating system 5 supplies the common UI and core services to thesoftware module developer 20-1. The software module developer 20-1 thendevelops one or more software modules at 212.

At 216, the AppBase 10 supplies extensions, definitions and themes tothe software application developer 30-1, and at 220 the operating system5 supplies the common UI and core services to the software applicationdeveloper 30-1. At 224, the software modules are supplied from thesoftware module developer 20-1 to the software application developer30-1, and the software application developer 30-1 then develops one ormore software application at 228. The software application developer30-1 then deploys the software application to the digital distributionplatform 40, at 230.

At 232, the software module developer 20-1 updates a software module,and then supplies the updated software module to the softwareapplication developer 30-1 at 236. The software application developer30-1 incorporates the updated module into the application at 240, anddeploys the updated application to the digital distribution platform at242.

For example, and as described further below, a gradle build system maybe used where a developed or updated module becomes part of a library,and a software application can use a specific version of the module oralways use the latest version of a module in the future. A notificationchannel may show changes in the latest version, and only the highestversion of the module may be included when putting everything togetherfor the application. Therefore, it is not necessary that the same entitycreates and uses a module, and multiple application could use a samesingle module once it is deployed.

Software Module Creation

FIG. 4 is a flowchart depicting an example method 300 of creating asoftware module. Although the example method is described below withrespect to the system 100, the method may be implemented in otherdevices and/or systems. At 304, control begins by extending a class fromAppBase.

At 308, control writes class extension code for the module. For example,control may create Android files, create sources, setup databases, etc.At 312, control creates activities, fragments and navigation componentsfor the module. For example, control may set up data that will be passedaround between modules or between applications.

Control creates layouts for user input at 316. At 320, controldetermines whether the module will use AppBase utilities. If yes,control obtains AppBase login and system resource utilities at 324, andproceeds to create test modules at 328. If the module will not useAppBase utilities, control proceeds directly to 328.

At 328, control creates test modules. The test modules may allow fortesting without integration of the developed software module, and mayprovide journal storing details. Unit and functional testing harnessescould be used to focus on one piece of the software module withouthaving to worry about how the software module will be integrated in asoftware application.

Control proceeds to prepare documentation and compile resources at 332,deploy artifacts at 336, and deploy the module at 340. In variousimplementations, JAVA docs and sources may be used, at 332, with anAndroid system resource compile. Tests may be set up before deployingthe artifacts at 336 or deploying the module at 340.

At 342, control determines whether any updated are needed to the model.For example, a module developer may determine that additional featuresshould be added to the model, etc. If yes, control proceeds to updatethe module at 344 by repeating steps 332, 336 and 340 for the updatedfeatures.

Referring again to FIG. 1 , in various implementations there may befunctional modules 20 and activity modules 20. The operations aredescribed using an Android operating system 5, but the concepts can beadapted to other operating systems (e.g., Apple iOS, etc.). To createeither type of module 20, AppBase 10 should be imported, for example,within a build.gradle file in a format consistent with the below:

-   implementation ‘com.mobile.base:App Base:1.0’

AppBase 10 includes the Module Base Definition class 14. The first partof creating a functional module 20 is to create a public class thatextends (or incorporates) the Module Base Definition class 14 to createa class that contains all of the information from Module Base Definitionclass 14 and adds more features to it. Extending this class is based onimplementing certain methods, but it serves to register the softwaremodule 20 with the generated software application 30 when it is firstproduced and the software module 20 will subsequently receivenotifications from the software application 30 when important eventsoccur (such as a change in the device configuration). Functional modules20 do not provide their own activities or navigation, so the relatedmethods do not have to be overridden. “Navigation” is a way ofspecifying the user path through an application 30, or alternativelyidentifying the specific places in an app 30 to which an end-user may godirectly. “Overriding” is a standard Java/Android term/practice commonthroughout many programming languages, which means that an extending (orincorporating) class can replace the contents of a method in theoriginal class. The created public class defines public methods asappropriate, as well as any helper classes that are needed for modulefunctionality.

Most software modules 20 contain their own database. (A module that doesnot define or contain its own database may be incapable of storingcomplex data. Sometimes this is fine, such as with the CRM module 20described above, which may not need to persist anything acrossapplication runs.) Managing the database at the module level allowsindependent database versioning when upgrading specific modules, as wellas allowing different database implementations (Module Base Definitionclass 14, SQLite/RealmDB) as appropriate for the task at hand. Whendefining the database name, package-specific naming should be used toprevent collision between module databases.

Creating an activity module 20 may include first creating a module classwith the functional module 20, then building out activities andfragments that interact with that functional module class 20. Thisallows activity modules 20 to define a UI and flow to be used whendesired, but also allows software applications 30 to interact directlywith the data as additional functionality. Activity modules 20 generallyhave a single activity entry point and handle internal navigation ontheir own (i.e., they may not require any application-specificnavigation handling to work correctly). Some modules 20, such as the“Programs” and “Journal” modules 20, are more complex and have multipleentry points, stored data, and specific navigation paths. In such acase, each activity should be returned from the getNavigableltems()method in module class 14, which means that this specific method shouldreturn 0 to many specific entry points into the module 20 that can beshown to the end-user for direct navigation.

Each Android activity and fragment contains a layout that dictates ordefines how individual components (e.g., GUI aspects) of the activity orfragment should be placed on the screen when presented to the end-user.Layouts for AppBase Activities may not include toolbars, menus, or otherapplication-level items. In AppBase, these are added by the application30 itself. When defining layouts and resources, a defining convention is“<moduleidentifier>_<resourcetype>_<resourcename>.” This preventscollision between module resources. Note, however, that this does notinclude the resources files themselves (strings.xml, etc.), but doesinclude the resource names.

When creating a module, the module 20 may be set up with dependencies onAppBase 10. Additionally, dependencies on CoreServices, CommonUl, orother modules 20 may be included. Modules 20 will be released as fullyfunctional entities ready to be consumed by an application 30, but arenot installable on devices on their own. As described above, the ModuleBase Definition class 14 in AppBase 10 is extended, then the moduleclass extension is populated with code specific and relevant to themodule 20. Next, data models, views and network/storage solutionsrelevant to the module 20 are created, and utility and peripheralclasses are created as necessary to complete the functionality of themodule 20. Finally, activities are created and navigation points arespecified to present functionality to the end-user.

The next step is to publish or deploy the module 20 (a functional oractivity module 20) (e.g., to a module repository 606, etc.). Publishingmay be necessary because without sending the completed code to anaccessible repository, other modules 20/applications 30 may not be ableto reference this module 20. A software module 20 can be publisheddirectly from a local Android Studio (an IDE), or from a continuousintegration (CI) build process like Jenkins. CI is a common developmentpractice to automatically create builds/artifacts for publishing whendefined criteria are met. The following code (for the Gradle buildsystem), for example, can be used to publish a module 20 to a modulerepository 606 configured as Maven repository. Note that the GroupID canbe shared, but the ArtifactlD+Version combination must be unique inorder to deploy successfully. ArtifactIDs should not be reused formodules with different purposes.

uploadArchives { repositories { mavenDeployer { pom.groupld =‘com.mobile.module’ pom.artifactld = ‘Journal’ pom.version = ‘0.1.0’snapshotRepository (url: mavenSnapshots) { authentication (userName:repoUser, password: repoPassword) } repository (url: mavenReleases) {authentication (userName: repoUser, password: repoPassword) } } } }

The convention for versioning is:

-   <major version>.<minor version>.<incremental version>

A major version number indicates a release with drastically differentcode, UI, or behavior. An app owner who moves up a major version shouldexpect more stability and/or functionality, but should also expect tomake changes to their code to accommodate the new version. A minorversion number indicates a change that adds a small amount offunctionality, or otherwise changes existing functionality in a way thatcan/will break unaltered applications. About 50% of the time, an appowner should expect to make changes to their code when a minor versionupdate occurs.

An incremental version could be a bug fix or patch, or a small amount ofnew functionality which is not immediately noticeable (like a new methodin a utility class). Incremental versions may not require applicationupdates, and may not be a cause for breakage. If things like methodsignatures are being altered without handling for backwardcompatibility, a minor version number increase may be used instead.

Filenames also have conventions defined, depending on the use and type,to prevent future collision of resource or activity names—for example,in a format consistent with the below. This is especially important whendealing with resources, because the Android System will overload/replaceidentically named items automatically.

-   Resources:<moduleidentifier>_<resourcetype>_<resourcename>

Here, moduleidentifier is a short, unique character sequence. Newmodules should ensure that the identifier chosen is not already in useby an existing module; resourcetype is the type of the resource, such as“icon”, “img”, or “color”; and resourcename is the specific name of theresource. This can be multiple parts and should be as specific as isnecessary to allow easy identification.

An example of a Resource name for the Journal module 20 is“journal_color_dashboard_background,” which uses “journal” as themoduleidentifier, “color” as the resourcetype, and“dashboard_background” as the name of the background color or image touse on a dashboard screen. Activities and Fragments should begin with ashort/common name for the module 20. For instance, the Journal module'smain activity that displays all journal entries is called“JournallistActivity.” Since the full package identifier can be used,this is more of a courtesy for consuming developers.

Modules 20 may be modified, but this should be done using a protocol. Tomodify an existing module 20, the module developer opens up the existingcodebase (e.g., codebase 604, etc.) in an integrated developmentenvironment (IDE). By convention, when using GIT, the latest version ofthe code should exist under the MASTER branch, but this may vary frommodule to module. Next, the module developer creates a new branch withinthis codebase to keep the new code separated until it is completed. Amodule may contain a standard test harness within its codebase formanually testing the different activities and functionalities providedby the module 20. This test harness is not a part of the moduleartifact, but exists solely for development purposes within thecodebase. (If the module developer adds new functionality to the module20, the developer should also add corresponding test code to the testharness.)

If the changes made to the module 20 are small and/or completelytestable with the test harness, the module can be released. The new codeshould be committed and merged with the main codebase branch beforerelease. If the changes made to the module 20 require more testing thanthe test harness can provide, the module developer can “sideload” themodule code with an existing application 30 (e.g., App 1 in FIG. 1 )using steps consistent, for example, with the below (which are specificto Android Studio):

The following may be added to the App 1 settings.gradle:

include ‘:<modulename>’ project(‘:<modulename>’).projectDir = newFile(‘<path_to_module_code_directory_on_developer's_machine>’)

Note that “modulename” is the name of the module that is being modified.And the following should be added to the App 1 build.gradle file toreference the local copy of the module being modified instead of theprevious (artifact) version:

//implementation ‘<artifact>’ implementation project(‘:<modulename>’)

Now when App 1 is compiled, it will be using the local version of theModule so that changes to the Module 20 can be tested. Once the testingis completed, these configuration changes to the App 1 codebase shouldbe reversed.

The details and location of this repository will differ betweenembodiments, so the method may include a packaging process. The modulename and information number, including the version number, are set inthe build system file (build.gradle on Android). If desired, a codedocumentation artifact such as Javadoc may be prepared. This artifactmay be released alongside the consumable module artifact (“.aar” inAndroid). Then, the consumable artifacts may be released or deployed toan artifact repository, such as Maven.

Software Application Creation

FIG. 5 is a flowchart depicting an example method 400 of creating asoftware application. Although the example method is described belowwith respect to the system 100, the method may be implemented in otherdevices and/or systems. At 404, control begins by creating anapplication class extension.

At 408, control determines whether any AppBase utilities are needed forthe software application. If yes, control proceeds to obtain AppBasecore services and common UI at 412, then proceeds to 416. If no AppBaseutilities are needed at 408, control proceeds directly to 416.

At 416, control sets a theme for the application, and sets parentactivities and fragments (e.g., a controlling activity that tells theapplication what to do initially). For example, a custom class extensionmay register modules and hook up navigation activities, fragments, etc.that are accessible from outside the application.

Control proceeds to identify applicable modules to be included in theapplication at 424, and then register an identified module to theapplication at 424. For example, a journal may extend an AppBase classand register the extended class to the software application. At 428,control compiles a list of module navigation options, such as a list ofwhat elements the module may navigate to. For example, a module may beregistered and the main application can execute a blast to search forlocations that the application can link to (e.g., navigation points),the navigation points may be manually set by a module developer, a mixof automatic and manual navigations settings may be performed, etc. Thiscan provide main and sub menus for the application.

At 432, UI components are added for the module. When the module becomespart of the application, the module may refer to an activity, fragment,etc., which may define a list of things that can be used, clicked on,etc. to add extra customization.

Control then determines at 436 whether an additional applicable model isneeded for the software application. If yes, control repeats steps 424,428 and 432 to add the additional module to the software application.Once no further modules are needed for the software application, controlproceeds to 440 to create login an authentication hooks. For example, inan application class the Android system may call an initializationprocess. The application class may wait to initialize a telehealthmodule until after a user login, and the initialization may occur anytime before the module is actually used. User login and logout featuresmay be part of core service manager calls, and the software developermay create login and logout hooks to the core (e.g., authentication,cookies, etc., where the service calls handle network stack features).

At 444, control builds the application, and then the application isreleased at 448 (e.g., for download/install from a digital distributionplatform, etc.). At 452, control determines whether any updates haveoccurred for imported modules of the software application. If yes,control builds the application at 444 with the updated module, andreleases the updated application.

Referring again to FIG. 1 , once a module 20 is published or deployed,it can be used by various software applications 30. This will vary basedon the current software application 30 as well as the specific module 20to be used. Here are a few of the most common use cases. For a softwareapplication 30 to use a functional module 20, the library should bereferenced from its build.gradle settings, for example, in a formatconsistent with the below:

-   implementation ‘com.module.wearable:SEIWearables:1.0’

Once included as a dependency, the module methods can be called as ifthey are part of the software app, for example, in a format consistentwith the below:

-   new WearableDeviceModule (this)

For a software application 30 to use an activity module 20, theapplication 30 must first be built on top of AppBase 10, which defines abase activity and fragment (for example, a screen model such as anActivity Class Extension 12 or Fragment Class Extension 13, etc.).AppBase 10 also assists with Android M permissions and navigationdestinations in a centralized manner. By using AppBase 10 as the root ofboth the software application 30 and the software modules 20, the twocan work with each other seamlessly with a minimal number of callbacksor compatibility issues. Again, AppBase 10 may be imported for thesoftware application 30 (e.g., within a build.gradle file, etc.), forexample, in a format consistent with the below:

-   implementation ‘com.mobile.base:App Base:1.0’

After building the software application 30 on AppBase 10 (includingusing (e.g., incorporating or extending, etc.) Application ClassExtension 11 for the app 30), an activity module 20 can be used byreferencing it from the Maven repository (e.g., a module repository 606,etc.), and calling its activity/activities, for example, in a formatconsistent with the below:

implementation ‘com.mobile.module:Journal:1.0’ new Intent (getContext(), JournalActivity.class)

Once a module 20 has been released, it is available for consumption fromthe hosting repository. For example, an AppBase application project iscreated, repository information is added to the build system, and themodule name+version is added to the dependency list (both of which arewithin build.gradle in Android). At boot, or at first desired use, themodule 20 is initialized with any required information. This may be acall to .initialize( )or a similar method within the module classextension, passing the application's context. In some cases, otherconfigurations are passed as well. Finally, the module 20 is ready foruse.

In various implementations, other operations or series of operations maybe used to generate a software module 20. For example, operations weredescribed using Gradle as a build system to configure AppBase 10.Android (and many systems) use Gradle to control builds, but there areother build systems as well which can similarly configure AppBase 10.Moreover, the actual order of the operations in the flowchart may not becritical.

As another example, the software application 30 must specify ApplicationClass Extension 11 (e.g., a software application model consistent withthat which is described above in reference to method 500, etc., or adescendant) in its AndroidManifest.xml. If the software applicationalready has its own class, then Application Class Extension 11 may beextended rather than using the basic android Application. This helpscontrol navigation, because this is the only place common to bothapplication code and modules, so lacking Application Class Extension 11may result in an inconsistent experience throughout an app 30. Theapplication class extension (or software application model) isspecified, for example, in a format consistent with the below inAndroidManifest.xml as:

<application android:name=“com.mobile.base.ApplicationClassExtension”android:theme=“@style/AppBaseTheme” . . . >

Application Class Extension 11 controls locale-locking (optional viaconfig.xml), navigation, user login/logout, and module management.Navigation (and the activities that may be navigated to) do not exist bydefault; navigation defined in software modules 20 may be addedautomatically for reference, but does not become the main navigation ofan application 30 unless set. For example, navigation is turned OFF bydefault as a safety measure (to ensure navigation provided by theapplication class extension is being used); to turn it on, thefollowing, for example, should be added to the extended ApplicationClass Extension 11:

@Override public boolean appUsesNavigation( ){ return true; }

To provide the list of navigable activities to the software application30, the getNavigationlist( )method in the extended application classextension 11 class must be overridden.

The software application 30 may specify in AndroidManifest.xml Theme 15(e.g., a theme consistent with that which is described above inreference to method 500, etc.) or an extension as its theme (the syntaxis shown in the above paragraph). Theme 15 sets some standards that canbe overridden as appropriate in the software applications 30. Typically,apps 30 will customize their theme by defining the AppBase Theme as the“parent” and replacing values as required. If a different theme is usedin the application 30 (or Theme 15 is reset), the software application30 may use an AppCompat theme with no action bar (the top area on anAndroid screen that contains title and other common elements), and mayprovide its own custom attributes, including menu background, menu itembackground, menu icon color, menu item text appearance, toolbar theme,toolbar pop-up theme, tab text color, tab selected text color, toolbaricon color, toolbar home icon, toolbar home left margin, and toolbartitle left margin. (AppCompat is a set of support libraries that may beused to make apps developed with newer Android versions operate witholder Android versions.)

The software application 30′s activities may extend Activity ClassExtension 12 (e.g., a screen model consistent with that which isdescribed above in reference to method 500, etc.). Activity ClassExtension 12 provides standardized layout and navigation handling thatapply to all applications 30 and activity modules 20.

The application fragments in the software application 30 may extendFragment Class Extension 13 (e.g., a screen model consistent with thatwhich is described above in reference to method 500, etc.). FragmentClass Extension 13 provides some helpful methods to app owners, but notall apps will use fragments and not all fragments will have use forthose methods. It is still recommended to extend Fragment ClassExtension 13 to allow for future support.

User management may be handled through the logInUser(user) andlogOutUser( )calls on Application Class Extension 11 (accessible via theapp( ) convenience method). (App( )is a reference to the currentinstance of Application Class Extension 11 from the current ActivityClass Extension 12 or Fragment Class Extension 13; it is a conveniencemethod, since typically there are several steps to obtain theapplication reference from an activity or fragment.) This allows boththe app 30 and any module 20 to access the current user ID at any timevia the command app( )getUserld( ). This is noteworthy, because manymodules will use the UserlD as the key to the storage methodology forthe modules.

Besides the operations described above, other operations or series ofoperations may be used to generate a software application 30. Moreover,the actual order of the operations in the flowchart may not be critical.

Software Application Startup

FIG. 6A is a flowchart depicting an example method 500 for starting up asoftware application. Although the example method is described belowwith respect to the system 100, the method may be implemented in otherdevices and/or systems. At 504, control begins by reading an applicationconfiguration file. For example, an xml file may include all applicationconfigurations (e.g., AppBase may define a default configuration and thesoftware application can override it for Android to manage things, suchas push notification, etc.).

At 508, control reads specified themes and styles for the application.The application may override a default theme from AppBase. For example,an application may use a different background color, variants ofdifferent clients may use different themes to distinguish one another,etc.

Control then determines whether the software application requiresnavigation at 512. If no, the control proceeds to 524. If theapplication does require navigation, control proceeds to set up thenavigation type at 516, and configures navigation destinations at 520.For example, in an application, navigation flags may be set thatindicate whether any modules of the application have navigation pointsto locate. Navigation types could include a bottom menu bar, a hamburgermenu, etc., which may be defined in a specific AppBase platform.

At 524, control configures application-wide options and menu items. Forexample, the application class may initialize a chat menu and set aflat, set objects in a global menu, add different items to an optionsmenu of the application, etc. At 528, control logins in a user, and thenan activity is started at 532 (which is described further in FIG. 6B).

Control determines whether a next activity is ready to start at 536. Ifso, control returns to 532 to run the next activity. For example, eachof the application may start in order, or run separately, after theapplication starts. Any number of activities can run at the same time,where one activity may run until finished then a second activity runsuntil finished, etc. In the Android operating system, each fragment ispart of an activity. An activity may have zero, one or multiplefragments, and each host fragment may have sub-fragments. Each activitybelongs to an application, with one application class in a softwareapplication. The application can have as many activities as desired.

FIG. 6B is a flowchart depicting an example method for starting up anactivity, which may occur at 532 in the method 500 of FIG. 6B. At 540,control determines whether the application incudes anapplication-specific override theme. If yes, control applies theapplication-specific override theme on top of the specified theme at544. At 548, control determines whether a layout is specified for theactivity. If yes, control sets a UI for the activity screen at 552.

Control then proceeds to 556 to determine whether there is an optionstoolbar menu for the activity. If yes, control adds all activity menuitem options at 560, and adds handling for when each menu item isselected at 564. Control then adds application-wide toolbar items at568. At 572, the activity is presented to the end-user.

Referring back to FIG. 1 , in various implementations the app ownerfirst determines the theme and styles for the app. In a conventionalapp, the standard Android theme elements, defined by the operatingsystem, may be configured via XML by the application. In addition to thestandard elements, AppBase 10 defines additional theme items forapplications to configure via XML by the application. Themes are handledat the base level, which is common to all applications 30 and modules 20built on AppBase 10, which means the specified theme(s) apply to everyvisible activity and fragment, presenting a seamless experience to theend-user.

When the application starts, navigation may be set up if required.Navigation destinations are configured by the Application 30 andreferenced from the AppBase 10 base activity class and, in particular,Application Class Extension 11. In this way, navigation is automaticallyset up for each individual activity as soon as it is created, and allmodules 20 built on (e.g., extending or integrating, etc.) AppBase 10(and therefore using the same common base class) can be used within anyapp 30 built on AppBase 10, and thus the same user experience will bepresented throughout.

This navigation setup differs from prior methods. Here, navigation isconfigured by the Application 30, whereas the prior method wasconfigured by the Activity (and thus occurred later in the flow). In theprior method, each Activity explicitly loaded the destinations andhandling - usually from a common utility method - because the ActivityUI includes the layout information, which needed to be present beforethe setup could continue. (A common utility method is a typicaldevelopment approach for navigation and other use cases in which asingle method is created in the codebase and is subsequently called byevery activity.) In turn, this meant that all Activities needed accessto all of the destination/handling data and/or the common utilitymethod, which precluded third-party libraries from being able to presentan identical user experience.

Next, supported/locked locales (languages) may be set up. AppBase 10adds the ability for app-configured locale locking. AppBase 10 containsXML, configurations for supported languages and default language, whichallows an app 30 to identify a specific set of locale content that maybe used. In this way, apps that include modules 20 that may havedifferent sets of content available can prevent the sometimes-availablecontent from being used, and present the end-user with a single-languageexperience.

This locale ability differs from the standard Android capability, whichallows for content to be provided in any number of languages, and theend-user's device locale will determine which content set will be used.If a matching set is available, that content will be loaded; if not, themain set (typically US English) will be used. When using third-partylibraries, this can result in different sections of the application 30rendering content in different languages (as available).

After setting up the locales, any application-wide options and menuitems may be added and configured. Similar to navigation, an Applicationcan configure toolbar items to be automatically placed on allactivities. This differs from the standard Android situation in whicheach activity sets up and configures its own toolbar menu, and iftoolbar items are common across multiple activities, each activity mustset those items up individually. Later, each activity may add its owncustom items to the toolbar menu so that the experience to the end-userwill be seamless throughout the app 30, while still allowing forspecific actions to be taken within activities.

Next, the Activity starts. An application-specific override theme willbe applied if available, the Activity layout is setup, and the Activitytoolbar is set up. AppBase 10 adds the ability to override theapplication theme at runtime, allowing for customized user experiencesbased on real-time data. Since this is handled in the basic (or base)class (e.g., Application Class Extension 11), the override theme (aswith the standard theme set up in operation 405) applies to all modules20 to present a seamless experience to the end-user. This differs fromstandard Android, which has no concept of an app-wide themeoverride—only the compile-time configured themes are used. If there isan application-specific override theme, that theme is applied on top ofthe default theme.

If there is a layout for this activity, the UI is set for the activityscreen and references to accessible fields are captured from the layout.With an application 30 built on AppBase 10, the Activity UI is concernedonly about its specific content—the toolbars, navigation anchors, andother “app-level” considerations are left to the platform. This differsfrom the standard Android case, in which the Activity UI would includethe entire renderable screen, including toolbars, navigation anchors,etc.

If there is an options or toolbar menu for the activity all menu itemoptions are added, and handling for when each menu item is selected isadded. After the override theme, layout, and options menu are selected,the activity is presented to the end-user.

Accordingly, a system and method for generating a software applicationare provided that provide standardization of design and implementationacross a family of software applications, allow discrete, standalonepieces of functionality to be written once and used across multiplesoftware applications, and allow service reuse according tofunctionality, eliminating the need to clone service layers fordifferent software applications. The aspects that differentiate thisapproach and help overcome some of the limitations of prior methodsinclude having an application codebase with extensions to theApplication, Activity, and Fragment classes, as well as a module classand a theme. This application codebase underlies the theme and stylesfor an application, allows navigation to be configured by theApplication, rather than by the Activity, and sets up locales andlanguages configured by the app. Having a common application codebase onwhich modules are built, when a module is updated, that update may bedistributed to each application that uses the module, thus reducing theworkload of the application owner.

Conclusion

The foregoing description is merely illustrative in nature and is in noway intended to limit the disclosure, its application, or uses. Thebroad teachings of the disclosure can be implemented in a variety offorms. Therefore, while this disclosure includes particular examples,the true scope of the disclosure should not be so limited since othermodifications will become apparent upon a study of the drawings, thespecification, and the following claims. It should be understood thatone or more steps within a method may be executed in different order (orconcurrently) without altering the principles of the present disclosure.Further, although each of the embodiments is described above as havingcertain features, any one or more of those features described withrespect to any embodiment of the disclosure can be implemented in and/orcombined with features of any of the other embodiments, even if thatcombination is not explicitly described. In other words, the describedembodiments are not mutually exclusive, and permutations of one or moreembodiments with one another remain within the scope of this disclosure.

Spatial and functional relationships between elements (for example,between engine) are described using various terms, including“connected,” “engaged,” “interfaced,” and “coupled.” Unless explicitlydescribed as being “direct,” when a relationship between first andsecond elements is described in the above disclosure, that relationshipencompasses a direct relationship where no other intervening elementsare present between the first and second elements, and also an indirectrelationship where one or more intervening elements are present (eitherspatially or functionally) between the first and second elements. Asused herein, the phrase at least one of A, B, and C should be construedto mean a logical (A OR B OR C), using a non-exclusive logical OR, andshould not be construed to mean “at least one of A, at least one of B,and at least one of C.”

In the figures, the direction of an arrow, as indicated by thearrowhead, generally demonstrates the flow of information (such as dataor instructions) that is of interest to the illustration. For example,when element A and element B exchange a variety of information butinformation transmitted from element A to element B is relevant to theillustration, the arrow may point from element A to element B. Thisunidirectional arrow does not imply that no other information istransmitted from element B to element A. Further, for information sentfrom element A to element B, element B may send requests for, or receiptacknowledgements of, the information to element A. The term subset doesnot necessarily require a proper subset. In other words, a first subsetof a first set may be coextensive with (equal to) the first set.

In this application, including the definitions below, the term “module”or the term “controller” may be replaced with the term “circuit.” Theterm “module” may refer to, be part of, or include processor hardware(shared, dedicated, or group) that executes code and memory hardware(shared, dedicated, or group) that stores code executed by the processorhardware.

The module may include one or more interface circuits. In some examples,the interface circuit(s) may implement wired or wireless interfaces thatconnect to a local area network (LAN) or a wireless personal areanetwork (WPAN). Examples of a LAN are Institute of Electrical andElectronics Engineers (IEEE) Standard 802.11-2016 (also known as theWIFI wireless networking standard) and IEEE Standard 802.3-2015 (alsoknown as the ETHERNET wired networking standard). Examples of a WPAN areIEEE Standard 802.15.4 (including the ZIGBEE standard from the ZigBeeAlliance) and, from the Bluetooth Special Interest Group (SIG), theBLUETOOTH wireless networking standard (including Core Specificationversions 3.0, 4.0, 4.1, 4.2, 5.0, and 5.1 from the Bluetooth SIG).

The module may communicate with other modules using the interfacecircuit(s). Although the module may be depicted in the presentdisclosure as logically communicating directly with other modules, invarious implementations the module may actually communicate via acommunications system. The communications system includes physicaland/or virtual networking equipment such as hubs, switches, routers, andgateways. In some implementations, the communications system connects toor traverses a wide area network (WAN) such as the Internet. Forexample, the communications system may include multiple LANs connectedto each other over the Internet or point-to-point leased lines usingtechnologies including Multiprotocol Label Switching (MPLS) and virtualprivate networks (VPNs).

In various implementations, the functionality of the module may bedistributed among multiple modules that are connected via thecommunications system. For example, multiple modules may implement thesame functionality distributed by a load balancing system. In a furtherexample, the functionality of the module may be split between a server(also known as remote, or cloud) module and a client (or, user) module.

The term code, as used above, may include software, firmware, and/ormicrocode, and may refer to programs, routines, functions, classes, datastructures, and/or objects. Shared processor hardware encompasses asingle microprocessor that executes some or all code from multipleengines. Group processor hardware encompasses a microprocessor that, incombination with additional microprocessors, executes some or all codefrom one or more engines. References to multiple microprocessorsencompass multiple microprocessors on discrete dies, multiplemicroprocessors on a single die, multiple cores of a singlemicroprocessor, multiple threads of a single microprocessor, or acombination of the above.

Shared memory hardware encompasses a single memory device that storessome or all code from multiple engines. Group memory hardwareencompasses a memory device that, in combination with other memorydevices, stores some or all code from one or more engines.

The term memory hardware is a subset of the term computer-readablemedium. The term computer-readable medium, as used herein, does notencompass transitory electrical or electromagnetic signals propagatingthrough a medium (such as on a carrier wave); the term computer-readablemedium is therefore considered tangible and non-transitory. Non-limitingexamples of a non-transitory computer-readable medium are nonvolatilememory devices (such as a flash memory device, an erasable programmableread-only memory device, or a mask read-only memory device), volatilememory devices (such as a static random access memory device or adynamic random access memory device), magnetic storage media (such as ananalog or digital magnetic tape or a hard disk drive), and opticalstorage media (such as a CD, a DVD, or a Blu-ray Disc).

The apparatuses and methods described in this application may bepartially or fully implemented by a special purpose computer created byconfiguring a general purpose computer to execute one or more particularfunctions embodied in computer programs. The functional blocks andflowchart elements described above serve as software specifications,which can be translated into the computer programs by the routine workof a skilled technician or programmer.

The computer programs include processor-executable instructions that arestored on at least one non-transitory computer-readable medium. Thecomputer programs may also include or rely on stored data. The computerprograms may encompass a basic input/output system (BIOS) that interactswith hardware of the special purpose computer, device drivers thatinteract with particular devices of the special purpose computer, one ormore operating systems, user applications, background services,background applications, etc.

The computer programs may include: (i) descriptive text to be parsed,such as HTML (hypertext markup language), XML (extensible markuplanguage), or JSON (JavaScript Object Notation), (ii) assembly code,(iii) object code generated from source code by a compiler, (iv) sourcecode for execution by an interpreter, (v) source code for compilationand execution by a just-in-time compiler, etc. As examples only, sourcecode may be written using syntax from languages including C, C++, C#,Objective-C, Swift, Haskell, Go, SQL, R, Lisp, Java®, Fortran, Perl,Pascal, Curl, OCaml, JavaScript®, HTML5 (Hypertext Markup Language 5threvision), Ada, ASP (Active Server Pages), PHP (PHP: HypertextPreprocessor), Scala, Eiffel, Smalltalk, Erlang, Ruby, Flash®, VisualBasic®, Lua, MATLAB, SIMULINK, and Python®.

What is claimed is:
 1. A computer system, comprising: a memorycomponent; a communication component configured to connect to acommunication network external to the computer system; transmit outputdata communications from the computer system via the communicationnetwork; and receive input data communications via the communicationnetwork; and at least one processor, communicatively coupled to thememory component and the communication component, the at least oneprocessor configured to: create a set of reusable software modules byextending a module base definition class from a codebase, wherein eachreusable software module of the set is independently created andagnostic to a particular software application, and wherein each reusablesoftware model defines a set of graphical user interface (GUI) aspects;for each reusable software module, create at least one activity for thereusable software module using an activity class extension from thecodebase, wherein the activity class extension provides a standardizedlayout and navigation handling that applies to all activities of allreusable software modules built from the activity class extension;programmatically build the software application, by: registering aplurality of reusable software modules from the set to the softwareapplication; and configuring navigation for each activity of eachreusable software module registered to the software application; andinitialize the software application as a configuration file, wherein theinitialization automatically applies a theme to each activity of eachreusable software module registered to the software application, andwherein the application of the theme unifies the set of GUI aspectsdefined by each reusable software module of the plurality of reusablesoftware modules registered to the software application to form a GUI ofthe software application.
 2. The computer system of claim 1, wherein theat least one processor is further configured to: update at least one ofthe plurality of reusable software modules, to generate an updated atleast one reusable software module; and in response to a previousversion of the at least one reusable software module having beenregistered to the software application prior to updating the at leastone reusable software module, register the updated at least one reusablesoftware module.
 3. The computer system of claim 2, wherein the at leastone processor is further configured to: maintain the previous version ofthe at least one reusable software module in the software applicationwhen the previous version of the at least one reusable software modulehad been registered to the software application prior to updating the atleast one reusable software module.
 4. The computer system of claim 2,wherein the at least one of the plurality of reusable software modulescomprises a general reusable software module from which at least oneother reusable software module depends.
 5. The computer system of claim4, wherein the at least one processor is further configured to: whenregistering the general reusable software module into the softwareapplication, remove the at least one other reusable software module fromthe software application.
 6. The computer system of claim 1, wherein theat least one processor is further configured to: create the set ofreusable software modules by obtaining common UI and core servicescomponents from an operating system; create the software application bycreating login and authentication hooks using the obtained core servicescomponents; and deploy the software application to a digitaldistribution platform.
 7. The computer system of claim 1, wherein the atleast one processor is further configured to: prior to creating the setof reusable software modules, receive the module base definition classfrom the codebase of an integrated development environment, via thecommunication component, wherein the codebase includes an applicationclass extension, the activity class extension, the module basedefinition class, and the theme.
 8. The computer system of claim 7,wherein the codebase further includes a fragment class extension; andwherein the application class extension, the activity class extension,and the fragment class extension comprise extensions of baseapplication, activity and fragment classes of an operating system. 9.The computer system of claim 7, wherein the at least one processor isfurther configured to: programmatically build the software application,by: registering the plurality of reusable software modules from the setto the software application using the application class extension; andconfiguring the navigation for each activity of each reusable softwaremodule registered to the software application using the applicationclass extension.
 10. The computer system of claim 1, wherein the atleast one processor is further configured to: apply the theme byapplying an application-wide override theme on top of a default themefor the at least one activity at startup of the at least one activity.11. A method, comprising: creating a set of reusable software modules byextending a module base definition class from a codebase, by at leastone processor communicatively coupled to a memory component, whereineach reusable software module of the set is independently created andagnostic to a particular software application, and wherein each reusablesoftware model defines a set of graphical user interface (GUI) aspects;for each reusable software module, creating at least one activity forthe reusable software module using an activity class extension from thecodebase, by the at least one processor, wherein the activity classextension provides a standardized layout and navigation handling thatapplies to all activities of all reusable software modules built fromthe activity class extension; programmatically building the softwareapplication, by: registering a plurality of reusable software modulesfrom the set to the software application; and configuring navigation foreach activity of each reusable software module registered to thesoftware application; and initializing the software application as aconfiguration file, by the at least one processor, wherein theinitialization automatically applies a theme to each activity of eachreusable software module registered to the software application, andwherein the application of the theme unifies the set of GUI aspectsdefined by each reusable software module of the plurality of reusablesoftware modules registered to the software application to form a GUI ofthe software application.
 12. The method of claim 11, furthercomprising: updating at least one of the plurality of reusable softwaremodules, to generate an updated at least one reusable software module;and in response to a previous version of the at least one reusablesoftware module having been registered to the software application priorto updating the at least one reusable software module, registering theupdated at least one reusable software module.
 13. The method of claim12, further comprising: maintaining the previous version of the at leastone reusable software module in the software application when theprevious version of the at least one reusable software module had beenregistered to the software application prior to updating the at leastone reusable software module.
 14. The method of claim 11, furthercomprising: creating the set of reusable software modules by obtainingcommon UI and core services components from an operating system;creating the software application by creating login and authenticationhooks using the obtained core services components; and deploying thesoftware application to a digital distribution platform.
 15. The methodof claim 11, further comprising: applying the theme by applying anapplication-wide override theme on top of a default theme for the atleast one activity at startup of the at least one activity, wherein thecodebase further includes a fragment class extension, and wherein theapplication class extension, the activity class extension, and thefragment class extension comprise extensions of base application,activity and fragment classes of an operating system.
 16. The method ofclaim 11, further comprising: configuring the at least one activity toset a user interface for a screen of the at least one activity, whereincontent of the user interface is determined by the at least oneactivity, and wherein arrangement of toolbars and navigation anchors ofthe user interface is determined by the software application.
 17. Themethod of claim 11, further comprising: creating at least one fragmentfor a respective reusable software module of the set using a fragmentclass extension from the codebase, the fragment class extensionproviding a standardized layout and navigation handling that applies toall fragments of all reusable software modules built from the fragmentclass extension; and configuring the software application to arrangenavigation for each fragment of each reusable software module registeredto the software application, to present a same user experiencethroughout the software application, wherein initializing the softwareapplication automatically applies the theme for each fragment of eachreusable software module registered to the software application, topresent a same user experience throughout the software application. 18.The method of claim 11, further comprising: creating the set of reusablesoftware modules by creating multiple reusable software modules, eachreusable software module including at least one corresponding activity.19. A non-transitory, computer-readable medium having instructionsthereon, which, when executed by a processor, perform a methodcomprising: receiving, from a codebase of an integrated developmentenvironment, a module base definition class, wherein the codebaseincludes an application class extension, an activity class extension,the module base definition class, and a theme; creating a set ofreusable software modules by extending the module base definition class,wherein each reusable software module of the set is independentlycreated and agnostic to a particular software application, and whereineach reusable software model defines a set of graphical user interface(GUI) aspects; for each reusable software module, creating at least oneactivity for the reusable software module using the activity classextension from the codebase, wherein the activity class extensionprovides a standardized layout and navigation handling that applies toall activities of all reusable software modules built from the activityclass extension; programmatically building the software application,including: registering, using the application class extension, aplurality of reusable software modules from the set to the softwareapplication; and configuring, using the application class extension,navigation for each activity of each reusable software module registeredto the software application; and initializing the software applicationas a configuration file, wherein the initialization automaticallyapplies the theme to each activity of each reusable software moduleregistered to the software application, and wherein the application ofthe theme unifies the set of GUI aspects defined by each reusablesoftware module of the plurality of reusable software modules registeredto the software application to form a GUI of the software application.20. The non-transitory, computer-readable medium of claim 19, the methodfurther comprising: creating the set of reusable software modules byobtaining common UI and core services components from an operatingsystem; creating the software application by creating login andauthentication hooks using the obtained core services components;applying the theme by applying an application-wide override theme on topof a default theme for the at least one activity at startup of the atleast one activity, wherein the codebase further includes a fragmentclass extension, and wherein the application class extension, theactivity class extension, and the fragment class extension compriseextensions of base application, activity and fragment classes of anoperating system; and deploying the software application to a digitaldistribution platform.